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Abstract — MIDEX (Medium Class Explorer) is the newest 
line in NASA’s Explorer spacecraft development program. 
As part of the MIDEX charter, the MIDEX spacecraft 
development team has developed a new modular, 
distributed, and scaleable spacecraft architecture that 
pioneers new spaceflight technologies and implementation 
approaches, all designed to reduce overall spacecraft cost 
while increasing overall functional capability. This resultant 
“plug and play” system dramatically decreases the 
complexity and duration of spacecraft integration and test, 
providing a basic framework that supports spacecraft 
modularity and scalability for missions of varying size and 
complexity. Together, these subsystems form a modular, 
flexible avionics suite that can be modified and expanded to 
support low-end and very high-end mission requirements 
with a minimum of redesign, as well as allowing a smooth, 
continuous infusion of new technologies as they are 
developed without redesigning the system. This overall 
approach has the net benefit of allowing a greater portion of 
the overall mission budget to be allocated to mission science 
instead of a spacecraft bus. The MIDEX scaleable 
architecture is currently being manufactured and tested for 
use on the Microwave Anisotropy Probe (MAP), an in- 
house program at GSFC. 
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L Introduction 

MIDEX (Medium Class Explorer) is the newest line in 
NASA’s Explorer spacecraft development program. 
Developed and managed out of Goddard Space Flight 
Center (GSFC), the program’s goal is to pursue “high-value” 
space science and astrophysics missions. In addition, the 
MIDEX program objectives include development and 


infusion of new technologies, architectures, and operations 
concepts which increase mission value by lowering cost and 
increasing capability. There is an emphasis on pioneering 
“high-risk” technologies via partnerships and collaborations 
with industry with the ultimate goal of transferring these 
technologies to industry for commercial spacecraft 
applications. 

It became clear at the beginning of the program that in order 
to accomplish these goals, significant changes would need to 
be made in the way that the MIDEX spacecraft hardware 
was designed and developed. Particular emphasis was paid 
to the spacecraft architecture itself and how lessons learned 
from previous GSFC spacecraft development efforts could 
be used in its development. This resultant “enabling 
architecture” would need to provide a flexible science 
platform that readily accommodated the increasing demands 
that science instruments place on spacecraft performance 
and operation, but at a fraction of the cost allotted on 
previous missions. The spacecraft architecture would need 
to be flexible, allowing high-end and low-end missions of 
wide ranging complexity to be configured from a single core 
design. The architecture would focus on using accepted 
aerospace industry standards and formats to reduce 
complexity, development time and cost, but still had to 
easily incorporate non-standard components and instrument 
platforms with minimal additional cost and development 
time. In addition, this architecture had to continue to 
outpace obsolescence in a world of exploding technology 
development and innovation. This could only be 
accomplished by allowing a clear path for rapid insertion of 
new, emerging technologies with minimal non-recurring 
expense to meet growing science requirements while 
continuing to reduce development and operating costs. 

By incorporating all of these derived requirements as a 
guide, a study team at GSFC was able to build upon the 
lessons learned from recent GSFC spacecraft in-house 
development efforts! 1] and capitalize on recent technology 



innovations (including a significant number of 
GSFC/industry joint technology development partnerships) 
to develop an advanced architecture concept for the MIDEX 
spacecraft development program. This architecture 
incorporates all of the original goals of the MIDEX 
development effort and falls within the cost and 
development restrictions placed by the MIDEX program. 
The first flight design, fabrication, test, and integration of 
the MIDEX spacecraft architecture is currently being 
manufactured and tested for use on the Microwave 
Anisotropy Probe (MAP), an in-house MIDEX spacecraft 
development program at GSFC. In addition, the architecture 
concept has been shown to be flexible and robust enough to 
meet a wide range of spacecraft requirements, a point 
apparently proven by that fact that since the introduction of 
the MIDEX spacecraft architecture at least two other NASA 
missions have adopted all or part of the MIDEX architecture 
and/or avionics units for use on their missions. In fact, 
various subsystems in the MIDEX architecture have been 
successfully commercialized under a NASA Space Act 
Agreement with Litton Amecom Division, which is now 
marketing these subsystem components for space 
applications. A significant number of commercial satellite 
vendors are in the process of studying the applicability of 
the MIDEX architecture and subsystem components to their 
spacecraft implementation requirements. 

2. MIDEX Architecture Overview 

A block diagram of the MIDEX scaleable architecture is 
shown in Figure 1. As part of the simplified interfaces 
designed into the architecture implementation, the primary 
interfaces to each of the subsystem electronics consists of 
the Dual-Rate 1773 fiber optic bus and spacecraft power. 

The MIDEX avionics units consist of the Power System 
Electronics (PSE) and the MIDEX Attitude Control 
Electronics (ACE)/Command and Data Handling (C&DH) 
unit (MAC). Both of these subsystems follow a similar 
distributed, modular design concept in their implementation 
approach. The subsystems utilize common cards sizes, 
enclosures, and formats and share a common Low Voltage 
Power Converter design which converts the Spacecraft 
power bus voltage down to the appropriate voltage levels for 
each of the subsystem applications. Each of the avionics 
subsystems utilize an expandable “building block” approach 
in their designs, coupled with a varied contingent of card 
types/configurations that can be inserted into the unit to 
provide the various capabilities required for a specific 
mission. In addition, each of the subsystems (and the 
instrument as well) utilize a Remote Service Node (RSN) 
design that allows them to interface all subsystem 
components to the spacecraft bus over the 1773 fiber optic 
interface, perform all subsystem-level commanding and 
telemetry collection, and utilize standardized software. The 
implementation of the RSN design into the MIDEX 
architecture simplifies testing and dramatically reduces 
integration time at both the spacecraft and subsystem levels. 
Finally, the modular design of the avionics was specifically 
engineered to allow a smooth, continuous infusion of new 


technologies as they are developed without redesigning the 
system. Together, these subsystems form a modular, 
flexible avionics suite that can be modified and expanded to 
support low-end and very high-end mission requirements 
with a minimum of redesign. Figure 1 illustrates this “high- 
end, low-end” configuration approach by indicating the 
minimum hardware per subsystem required for a simple 
spacecraft implementation. At the same time, the MIDEX 
subsystems have been designed in a modular, scaleable 
fashion to expand in functional capability by adding cards to 
the subsystem implementation. 
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Figure 1 MIDEX Architecture Block Diagram 

The following is a functional description of the MIDEX 
Spacecraft architecture. Although the baseline 

implementation shown here illustrates a single string (non- 
redundant) implementation, the actual architecture 

implementation can be readily modified to incorporate 
various levels of redundancy with minimal impact. In the 







MAP spacecraft implementation of the MIDEX architecture, 
the project was initially directed to pursue a single-string 
spacecraft architecture design approach. However, a move 
was later made to modify the MAP flight architecture to 
incorporate redundancy late in the development effort. This 
change was made in response to suggestions by an 
independent review team to increase the MAP mission’s 
overall chances of success in light of the tremendous value 
of the anticipated science and the growing interest from the 
world astrophysics community. As a result of these 
recommendations, changes were made to the MAP 
architectural implementation late in the program at a 
relatively minor cost impact and virtually no schedule 
impact, again demonstrating the flexibility and value of the 
MIDEX architecture. 

AS 1 773 Fiber Optic Data Bus 

The AS 1773 fiber optic bus is a key enabling technology for 
the MIDEX architecture. As previously mentioned, the 
AS 1773 bus performs as a simple, standardized, inherently 
redundant command and data interface throughout the 
spacecraft. In addition, it provides many other benefits such 
as higher data rates, EMI isolation, and lower overall mass 
and power consumption than other comparable 
implementation approaches. The AS 1773 implementation 
will allow dual data rates of 1Mbps and 20Mbps between 
the MIDEX spacecraft components (although the MAP 
spacecraft will initially implement only the 1 Mbps data rate 
capability). The AS1773 bus is a continuation of GSFC’s 
ongoing use and experience with time-multiplexed fiber 
optic data busses in spaceflight applications, including the 
Solar Anomalous Magnetospheric Particle Explorer 
(SAMPEX) (launched in 1992)[2], X-Ray Timing Explorer 
(XTE) (1995)[3], Hubble Space Telescope (HST) Solid 
State Recorder (SSR) (1997) and the Tropical Rainfall 
Measurement Mission (TRMM) (1997). 

Remote Services Node (RSN) Concept 

At the core of the MIDEX architecture and its modular 
distributed approach is the implementation of the Remote 
Service Node (RSN) concept. The RSN concept is based 
around the Essential Services Node (ESN) Multi-Chip 
Module (MCM), which acts as a low cost, rad-hard, 
processor-controlled flexible interface device[4-5]. By 
implementing RSN technology throughout the spacecraft, all 
spacecraft subsystem commanding and telemetry collection 
can be processed at the subsystem level in the individual 
RSNs. In addition, the RSN implementation also allows the 
subsystems to be configured in such a way so as to make the 
1773 bus and power the primary subsystem interfaces to the 
spacecraft. These simple, standard interfaces significantly 
simplifies complexity and decreases the time required for 
the integration and test of the subsystem with the rest of the 
spacecraft 

Figure 2 illustrates the method by which the ESN is 


implemented in spacecraft subsystems and components as a 
standard interface component. The custom interfaces which 
previously required complex interfaces at the spacecraft 
level are now relegated to the subsystem level, allowing 
them to be tested and verified during subsystem-level 
testing. As a result, the primary interfaces at the spacecraft 
level are the 1773 fiber optic bus and power, which greatly 
simplifies the spacecraft interfaces as well as 
dramatically reducing spacecraft testing and integration. In 
addition spacecraft power distribution is now distributed to 
the various spacecraft subsystem components, which switch 
them via a solid-state circuit breaker under RSN control. 
The result is a spacecraft avionics suite that is modular, 
distributed, equipped with simple, standardized interfaces 
that facilitate more comprehensive subsystem 

28 Volt Bus 



Figure 2 ESN Implementation in the MIDEX Architecture 

level testing and simplified spacecraft level integration and 
test. In addition, non-standard components can be easily 
integrated into the MIDEX architecture with a minimum of 
additional design by the addition of the ESN as a standard 
interface component. 

The use of the ESN MCM in the RSN designs also allows 
the additional benefit of enabling software standardization 
throughout all of the RSNs in the spacecraft. In the MAP 
implementation, for example, the flight avionics 
development team developed a Generic RSN Core design 
common to all of the RSNs on the spacecraft. This standard 
RSN design implementation (known as the Generic RSN 
Core) encapsulates all of the basic design requirements that 
were required in the MIDEX architecture implementation. 

The Generic RSN core design covers approximately half of 
one side of a 9.7” x 8.4” MAP standard flight surface-mount 
card, leaving the remaining half-side as well as the alternate 
side of the flight card for the designer to implement the 
application specific design required for the specific 




subsystem application. The diagram in Figure 3 illustrates 
this implementation approach, as well as identifying the 
standard backplane and faceplate connectors 
used by the Generic RSN Core design. This implementation 
approach results in a tremendous of amount of hardware and 
software commonality between subsystem RSN 

implementations on the spacecraft. In fact, with the 

exception of the Attitude Control Electronics (ACE) RSN 
(which implements an independent safehold capability and, 
therefore, has a significantly larger application-specific code 
usage), the RSNs in each of the spacecraft and instrument 
subsystems have a common flight software code use of 
between 57% (Instrument RSN) and 81% (XRSN) of total 
flight code per card. This commonality in hardware and 
software simplifies both hardware and software interfaces, 
once again allowing increased capability at a lower cost. 



Figure 3 Generic RSN Core Implementation Approach 

The Generic RSN Core design also has a standard interface 
to the standard LVPC card designs used in the MIDEX 
architecture. Through this command interface, each RSN 
controls the LVPC switched power outputs by 

communicating over a standard backplane design. These 
LVPC switched power outputs are, in turn, used to provide 
power to subsystem components. In addition, the 
RSN/LVPC combination is used to provide autonomous 
spacecraft heater control for each subsystem, with the RSN 
reading subsystems thermistor telemetry and switching on 
and of subsystem heaters via the LVPC in order to maintain 
the desired thermal environment. 

The actual Generic RSN hardware implementation on the 
MIDEX standard 9.7” x 8.4” flight card size is shown in 
Figure 4. 



Figure 4 Actual Generic RSN Eiardware Implementation 


Power Supply Electronics (PSE) 

The guiding principles for the MIDEX PSE subsystem 
design were similar to those of the rest of the MIDEX 
spacecraft architecture: that the PSE design must readily 
apply to the implementation requirements of multiple 
missions. In practical terms, this meant that the PSE design 
must be able to accommodate the following requirements: 
the external interfaces must be simplified and standardized 
to reduce the costs of subsystem and spacecraft level test 
and integration, and the PSE must be designed to allow the 
use of cost reducing technology advances in solar arrays and 
batteries. In addition, the PSE design must have a modular 
power output implementation approach to support baseline 
missions with up to 400 W orbital average loads in LEO 
orbits with solar arrays oriented towards the sun, as well as 
the ability to accommodate higher power missions with 
minimal size, weight, and cost growth. 

The PSE subsystem consists of the following hardware 
components: the PSE RSN, Power Distribution Modules, 
Battery Interface Modules, and Solar Array Interface 
Modules. 

PSE RSN Card - The PSE RSN (shown in Figure 5) is the 
central processor in the PSE electronics. Based around the 
Generic RSN Core electronics, this card provides digital 
control of all of the PSE functions and modules. A number 
of control algorithms can be implemented in the PSE RSN 
to adapt to a wide variety of spacecraft mission requirements 
and PSE configurations. The RSN provides the power 
system with autonomous control — all power system 
functions and fault detection and correction can be managed 
within the subsystem. In addition, having the power system 
control algorithm accomplished in table-driven software 
allows for flexibility in power system component 
interfacing. Any battery technology or solar array size can 
be accommodated by adjusting calibration constants and 
signal gains in the software and adjusting jumpers on the 
interface boards. The system transient response to load 
changes can be tuned to various mission power profiles by 
simply modifying software control factors. 



Figure 5 PSE RSN Card 


Power Distribution Modules- The PSE Power Distribution 
Modules provide both switched and unswitched power to the 
various spacecraft subsystems. The modular design of the 
PSE unit supports the capability to hold up to three power 
distribution modules, depending upon the power 
requirements and configuration of the selected spacecraft. 
This is the total number of Power Distribution Modules that 
can be implemented in the baseline PSE design 
configuration without forcing additional design and cost The 
Power Distribution Modules rely entirely on solid state 
power switching technology (instead of relays), the status of 
which is constantly monitored by the PSE RSN. These solid 
state switches provide resettable overcurrent protection of 
the loads without fuses. 

Battery Interface Modules- The Battery Interface Module 
provides the electrical interface by which the spacecraft 
batteries provide power to the spacecraft or are charged and 
conditioned via the spacecraft solar arrays. The modular 
design of the PSE allows the use of up to two Battery 
Interface Modules (once again, without incurring redesign 
and cost), depending upon the number and size of the 
batteries required for the particular spacecraft. Any battery 
technology (NiCd, NiH2, Li Ion) can be incorporated with 
minor adjustments in software and firmware. Battery sizes 
up to 50 Amp-hours per module can be used. 

Solar Array Interface Modules - These modules provide the 
interface between the PSE and the spacecraft solar arrays. 
Up to three Solar Array Modules can be implemented in a 
modular fashion in order to configure the PSE subsystem to 
meet the solar array power generation requirements dictated 
by the spacecraft. The Solar Array Interface Modules are 
adaptable to multiple solar array sizes of up to 750 Watt per 
card by installing jumpers and modifying software constants. 
Power dissipating solar array shunts have been replaced 
with rad-hard, solid state, nondissipating FETs (Field Effect 
Transistors) with low on resistance. 

Command & Data Handling ( C&DH) 

The MIDEX C&DH system (which is housed in a common 
enclosure with the ACE subsystem electronics) functions as 
the sole interface between the MAP spacecraft/instrument 


subsystems and the ground operations equipment. The 
C&DH system acts as a command decoding and distribution 
system, a telemetry/data handling system, and a data storage 
and playback system. It provides on-board computational 
capability for processing attitude sensor data and generating 
commands for the attitude control actuators in a closed-loop 
fashion. It also provides stored command processing and 
monitoring of the health and safety functions for the 
spacecraft and instrument subsystems. 

The C&DH consists of the following hardware components: 
the Mongoose V Spacecraft Processor and Solid State 
Recorder (SSR) Card, Transponder RSN Card, and 
Housekeeping RSN card. 

Mongoose V Spacecraft Processor/SSR Card- The 
Mongoose V 32-bit Rad-hard RISC Processor card (shown 
in Figure 6) acts as the spacecraft central processor in the 
MAP spacecraft implementation and is responsible for the 
bulk of the spacecraft processing capability. The Mongoose 
V processor card also acts at the Bus controller (BC) on the 
Spacecraft 1773 fiber optic bus. The processor card also 
includes 320 Mbytes of on-board stacked DRAM used for 
processor local memory and spacecraft SSR. This DRAM is 
configured in the following manner: 256 Mbytes (64M x 32) 
of actual data storage and 64 Mbytes (64M x 8) of DRAM 
dedicated to Error Detection & Correction (EDAC). 



Figure 6 Mongoose V Processor/SSR Card 


In addition, the Mongoose V Processor card also includes 

the following capabilities: 

- 4 Mbytes of jumper-configurable EEPROM, divided into 
protected, write-protected, and flight-writeable areas; 

-Spacecraft Time Keeper, which maintains Mission Elapsed 
Time in seconds and sub-seconds; 

-Watchdog Timer Circuit, which provides a timed reset 
capability; 

-External Timer, which provides a timed interrupt 
capability; 




-Medium Speed Serial Port (MSSP) to transfer data serially 
to the MAP Transponder RSN (XRSN) via an RS422 
interface; 

-Hardware Data Compression option; 

-External Waitstate Generators. 

Transponder RSN (XRSN)- The XRSN (shown in Figure 7) 
provides the Command and telemetry link between the 
C&DH subsystem and the ground system. Its is based 
around the Essential Services Node (ESN) Multi-Chip 
Module (MCM) and uses a modified version of the Generic 
RSN design and layout. The XRSN shall receives CCSDS 
(Consultative Committee for Space Data Systems) uplink 
codeblocks from the transponder and passes them to the 
C&DH. The XRSN also receives CCSDS downlink frames 
from the C&DH, formats and encodes them, and sends them 
to the transponder for transmission to the ground system. 
The maximum Uplink data rate possible with the XRSN is 
10 Kbits/sec. The maximum transfer rate (data and 
encoding) from the XRSN to the GN transponder (which is 
used in the MAP spacecraft implementation) for downlink 
telemetry is 6 Msymbols/second. 



Figure 7 XRSN card (showing alternate side of card) 


The XRSN interfaces with the C&DH via a serial RS422 
telemetry interface and the 1773 bus. The High-Rate 
Telemetry interface provides the XRSN with high-rate 
telemetry frames to downlink. The 1773 bus provides the 
XRSN with the following: XRSN commands, GN 

transponder commands, low-rate telemetry frames to 
downlink, and time-code updates. The 1773 bus provides 
the C&DH with the following: uplink codeblocks, GN 
transponder housekeeping telemetry, and XRSN 
housekeeping telemetry. 

The XRSN has the capability to decode and distribute up to 
eight (8) special hardware commands. These discrete 
command signals (hardware decoded discrete commands 
wired from the XRSN to the affected subsystem interface) 
are used to change the configuration of the MAP spacecraft 
independent of the 1773 bus. 


For the MAP spacecraft implementation, the XRSN is 
designed to interface to either the Loral Ground Network 
(GN) transponder or the Fourth Generation TDRSS 
Transponder. If interfacing to the GN transponder, the 
XRSN shall interface the transponder to the C&DH via the 
1773 bus, controlling the transponder mode and sampling 
transponder status. 

Housekeeping RSN (HRSN)- The Housekeeping RSN 
(HRSN) is responsible for two primary functions. First, it 
performs all of the C&DH subsystem-level housekeeping 
telemetry collection and discrete commanding associated 
with the subsystem. Second, it performs MAP spacecraft 
level housekeeping telemetry collection and discrete 
commanding associated with various spacecraft components 
not associated with another subsystem. 

The HRSN design is based on the Generic RSN Core design 
and layout. The HRSN builds upon this design to provide 
housekeeping telemetry collection and discrete commanding 
functions to the C&DH subsystem and the MAP Spacecraft. 
This command and telemetry collection capability 
interfaces to the MAP architecture via a MIL-STD-1773 
bus. 

As an example of the HRSN implementation and use, in the 
MAP spacecraft implementation the HRSN performs the 
following functions: 

-Spacecraft Thermistor & Voltage Monitoring; 

-Spacecraft RF Network Switch Relay Commanding and 
Status Monitoring; 

-Spacecraft Heater Control via C&DH Low voltage Power 
Converter (LVPC) 28 V switched power outputs; 
-MAP/Launch Vehicle Separation Signal Monitoring and 
Distribution; 

-Solar Array Deployment Activation; 

- Spacecraft Telemetry Monitoring. 

Attitude Control Electronics (ACE) 

The MIDEX ACE subsystem (which is housed in the same 
enclosure as the C&DH subsystem) acts as the primary 
interface between the spacecraft and the attitude control 
system (ACS) sensors and actuators, as well as providing an 
independent safehold capability to the spacecraft. The ACE 
implementation is a perfect example of the true value of the 
MIDEX architecture implementation since the type of 
attitude control sensors and actuators selected are highly 
dependent upon the specific mission and operational 
scenarios of a particular spacecraft. In addition, these 
components usually procured with varied interface options 
that are I/O intensive, usually require custom interface 
circuitry and would not naturally fit into the MIDEX 
standardized 1773 bus architecture. Finally, there is the 
issue of distributing power from the spacecraft to the ACE 
peripheral components so that the ACE subsystem has the 
capability to turn on and off the components as required. 
This creates the problem of dealing with custom interfaces 





that tend to vary significantly from spacecraft to spacecraft, 
making it difficult to come up with a simple, standard 
interface approach that can be used across multiple missions 
with minimal redesign and non-recurring expense. 

The MIDEX ACE architecture implementation addresses 
this problem by augmenting the Generic RSN Core design 
with extended input/output (I/O) interface capabilities 
implemented using Field Programmable Gate Arrays 
(FPGAs) in order to increase flexibility for redesign between 
missions. The ACE I/O design also provides as many 
potential I/O options as possible, allowing the spacecraft 
vendors to utilize commercial products and thereby keep the 
attitude control components cost down. The ACE I/O 
electronics design will be as flexible as possible to these 
interfaces, designed to support low-cost reconfiguration of 
the ACE interfaces as needed. A MIDEX common LVPC 
under RSN control is used to provide power switching to 
attitude control components. 

As a result, the spacecraft to ACE subsystem interfaces 
comply with MIDEX architecture guidelines, consisting 
primarily of the 1773 fiber optic bus and power. In 
addition, a suite of ACE I/O cards can be developed to 
combine ACS component interfaces common to specific 
mission types on a set of ACE cards Eventually, these 
cards can provide a library of ACE configuration options 
that can be put together with minimal redesign to support 
specific mission requirements. The ACE configuration for 
the MAP mission consists of the following hardware 
components: the ACE RSN Card, Sensor I/O Card, and 
Propulsion I/O card. 

ACE RSN Card- The ACE RSN card (shown in Figure 8), 
which is based upon the MIDEX Generic RSN Core design, 
provides telemetry collection and commanding for the 
attitude control sensors and actuators. In addition, the ACE 
RSN provides a hardware platform for the spacecraft 
independent safehold capability. In the MAP spacecraft 
implementation, the interfaces of spacecraft ACS sensors 
deemed critical for safehold operation have been designed 
onto the remaining card area of the ACE RSN flight card, 
providing a reliable, single card safehold processor that 



does not rely on any other off-card interfaces for operation. 
The Digital Sun Sensor (DSS) interface has also been 
designed into the ACE RSN card because it utilizes features 
already available via ESM MCM services. 

Sensor I/O Card- The Sensor I/O card collects attitude 
control sensor information and transfers it to the ACE RSN 
for use in spacecraft attitude control calculations. In 
addition, the Sensor I/O card gathers spacecraft telemetry 
critical to spacecraft attitude control operation (such as solar 
array deployment information, spacecraft/launch vehicle 
separation signal, etc.). As mentioned previously, the actual 
sensor interface designs resident on this card may vary 
significantly based on the ACS components required for a 
specific mission as well as the actual ACS components 
manufacturers and interface options selected. The modular 
nature of the ACE and Sensor I/O card design supports 
changes in the ACS sensor contingent without massive 
subsystem redesign and associated NRE. In addition to these 
other functions, all ACS subsystem and component 
thermistors are monitored by the Sensor I/O card. 

Propulsion I/O Card- The Propulsion I/O Cardis the sole 
interface for all command, control and telemetry interfcaes 
to the MAP propulsion system. This card provides the 
control capability to up to eight thrusters used in the MAP 
spacecraft ACS implementation. In addition, the Propulsion 
I/O card collects and monitors telemetry the MAP fuel tank 
pressure transducer, thruster temperature sensors, and is 
responsible for commanding and telemetry for the fuel tank 
isolation valve Depending on the particular ACS 
requirements of the spacecraft, a different card can be 
designed and substituted that meets other mission 
requirements. For example, the Propulsion I/O Card can be 
removed and a Magnetic Torquer Bar I/O card can be 
substituted for missions requiring that type of ACS control 
mechanism. 

3. MIDEX Enabling Technologies 

New technology advances and infusion into spaceflight 
hardware has been a critical factor in realizing the MIDEX 
architecture concept. A few of the more important 
technology advancements that have enabled the MIDEX 
architecture implementation were the development of the 
Mongoose V Rad-hard 32-bit flight processor, the Essential 
Services Node (ESN) Multi-Chip Module (MCM), the Dual- 
Rate Fiber Optic data bus, and High-Density Stacked 
DRAM. Each of these advancements has increased 
spacecraft capability while dramatically lowering overall 
spacecraft avionics cost, weight, and size. 

Mongoose V Rad-Hard 32-bit Processor 

The Mongoose V single-chip processor (Figure 9) was 
developed under a collaboration with GSFC, Synova Corp., 
and Honeywell Solid State Electronics Center (SSEC)[6]. 
The Mongoose V contains the following features: 


Figure 8 ACE RSN Card 


-MIPS-compatible CPU; 




-On-chip Floating Point Unit (FPU) (compatible with 
ANSI/IEEE Standard 754-1985; 

-On-chip instruction and data cache memory; 

-Bus Interface Unit (BIU), including a programmable wait- 
state generator; 

-Internal DRAM controller; 

-Two 32-bit counter/timers; 

-8-bit modified memory Error Detection and Correction 
(EDAC)(provides single-error correction and double- 
error detection); 

-Two Asynchronous UARTs with 825 1 -compatible I/O; 

- Commercial off-the-shelf (COTS) development tools. 



Figure 9 Mongoose V 32-bit Rad-Hard Processor 


The capabilities of the Mongoose V processor have allowed 
increased capability with substantial savings in cost and 
weight over the XTE C&DH subsystem, a previous in- 
house GSFC spacecraft (launched 12/97) which utilized a 
state-of-the-art C&DH system as part of the spacecraft 
avionics suite). The increased processing power of the 
Mongoose V processor allows it to perform as the 
Spacecraft central processor as well as the Attitude Control 
System processor in the MIDEX spacecraft architecture. 
The processor also includes an embedded Error Detection 
and Correction hardware capability, allowing the use of 
inexpensive and dense DRAM for processor program 
memory. The combination of both of these factors results in 
a capability increase, while also providing a corresponding 
reduction in size, weight, and a recurring cost reduction of 
well over $1 .5 M per C&DH avionics unit. 


Essential Services Node (ESN) Multi-Chip Module (MCM) 

The ESN (Figure 10), which was developed as part of a 
cooperative effort between GSFC and Honeywell Space 
Systems, is an analog/digital standard interface component 
in a MCM package that performs many spacecraft functions 
and is used to standardize subsystem interfaces and support 
the modular MIDEX architecture concept[4-5]. 



Figure 10 ESN MCM (showing analog and digital layers) 


The ESN MCM contains the following features: 

-MIL-STD 1553B/1773 interface 

-UTMC UT69R000 microcontroller w / 32 kwords of 
onboard program memory, 32 kwords of onboard data 
memory, 32 kwords of onboard shared memory 
-Two 8251 UARTs 
-8255 port device 

-16-bit serial to parallel and parallel to serial converter 

- 8254 counter/timer 

-12-bit A/D converter 

-Analog power strobing 

-Sleep mode for power conservation 

-Watchdog timer, Subseconds timer, Time management 
service 

-Rad-hard component (TID 100 kRad- no SEUs or latchup). 
Dual- Rate Fiber Optic Data Bus 

The use of the fiber optic bus (described previously) is a 
continuation of GSFC’s flight fiber optic bus experience in 
in-house spacecraft. The use of the AS 1773 bus 
implementation will allow the use of higher data rates (20 
Mbps) than previously available over the spacecraft 1773 
bus. Not only does this increase spacecraft on-board data 
collection and telemetry transmission rates, but it will allow 
a more widespread use of the fiber optic bus for on-board 
data transmission in cases where higher data rate or data 
volume requirements prohibited the use of the 1 Mbps data 
bus. The elimination of discrete interfaces will, in turn. 




continue the trend towards simplifying spacecraft interfaces 
and decrease the complexity, time, and cost required for 
subsystem and spacecraft integration and test. The MAP 
spacecraft design utilizes the Boeing Dual-Rate Transceiver 
for the 1773 fiber optic bus interface implementation. A 
typical flight card implementation of the 1773 fiber optic 
components is shown in Figure 1 1. The fiber optic pigtails 
used in the transceiver design provide a tremendous degree 
of flexibility in selecting actual parts and connector 
placement of the device. 



Figure 11 Typical MAP 1773 Fiber Optic Interface 


High Density Stacked DRAM- The use of high-density 
stacked DRAM allows dramatically greater spacecraft 
memory storage capability at a fraction of the size, weight 
and cost of previous implementation approaches. For 
example, GSFCs most recent in-house spacecraft 
development efforts, XTE (launched 12/95 from KSC, FL) 
and TRMM (launched 11/97), both utilized similar state-of- 
the art C&DH systems in their implementations. The advent 
of a high-density stacked DRAM implementation (whose 
initial development was funded as part of a collaboration 
under a GSFC-led SBIR effort) was first flown in the HST 
SSR (part of the HST retrofit during the 1997 HST 
refurbishment mission). Since then, similar DRAM 
packaging has been implemented in the MIDEX 
architecture. In fact, while the TRMM SSR implementation 
required 14 flight cards (~8.5” x 10” each) to support a 2 
Gbit memory capability, the MIDEX DRAM SSR 
implementation actually resulted in greater memory storage 
capability (over 2.5 Gbits) in a flight card area of - 1/8 of a 
similarly sized card. This increased capability while 


decreasing size (by over 13 flight cards), decreased weight 
(by ~30 lbs), and decreased recurring costs (by well over 
$1M per SSR). 

4. MIDEX Architecture Advantages 

The advantages and benefits of the MIDEX scaleable 
architecture can be described in the following categories: 

Simplified/Standardized Interfaces 

The adoption of standardized interfaces has been shown to 
dramatically cut spacecraft complexity, integration and test 
time, and overall cost. Custom interfaces have the double- 
edged impact of increased time and cost for development, 
maintenance and documentation, as well as increasing time 
and manpower required for integration and test. The 
MIDEX architecture emphasizes simple, standard interfaces 
designed to decrease development, test and integration as 
well as provide a simplified route to interfacing with other 
components on the spacecraft. 

In the MIDEX architecture, the primary electrical interfaces 
between the subsystem components on the spacecraft are the 
1773 fiber optic time multiplexed data bus and power. 
Discrete wire interfaces are scrupulously avoided whenever 
possible. Lessons learned from the X-Ray Timing Explorer 
(XTE), a spacecraft developed at GSFC and launched on 
Dec. 30, 1995, demonstrated the immense benefit of the 
1773 fiber optic data bus in simplifying and shortening 
spacecraft integration and test, with a resultant decrease in 
manpower and cost [3]. Although the MIDEX architecture 
was designed with a AS 1773 fiber optic bus implementation 
(which boasts dual-rate time-multiplexed data rates of 1 and 
20 Mbps), the initial implementation in the MAP spacecraft 
development program utilizes only the 1 Mbps data rate. 

Distributed Architecture 

In the MIDEX architecture implementation, power 
distribution, command decoding and telemetry collection are 
done in a distributed fashion at the subsystem component 
level rather than in a centralized fashion. This provides a 
number of tremendous benefits to the spacecraft 
development effort. Overall system level fault tolerance is 
increased since services and command/telemetry interfaces 
are distributed rather than located at a single point. The 
decentralized nature of the architecture also allows full 
testing of stand-alone subsystems apart from integration with 
other spacecraft components, decreasing the complexity and 
duration of spacecraft level I&T. 

The implementation of the distributed architecture has been 
enabled by the implementation of two critical technologies. 
The first, the 1773 fiber optic bus, permits a simplified, 
naturally redundant standardized command and data 
interface throughout the spacecraft. The second, the 
Essential Services Node (ESN) (described later), allows 
non-standard components to easily interface with the 1773 




bus in a standardized, low-cost fashion with minimal NRE. 
The ESN implementation also allows the spacecraft 
commanding and telemetry collection to be performed at the 
subsystem level in the decentralized fashion described 
above. 

Modular design 

All of the electronic subsystems in the MIDEX architecture 
(as well as the spacecraft implementation itself) follows 
modular, standardized design approach. Subsystem 
components are designed around a modular, building block 
approach that emphasizes standard services, cards, 
enclosures, and formats. This allows subsystems which can 
be readily configured to suit specific mission requirements. 
Ultimately, the MIDEX implementation approach will allow 
spacecraft designers to configure subsystem electronics from 
an existing library of cards and capabilities, tailoring the 
various subsystem capabilities to meet their mission’s 
custom needs and requirements. 

Non-Proprietary Architecture and Development Tools 

The MIDEX development approach, as a rule, emphasizes 
the use of non-proprietary, commercially available industry 
standard formats, architectures, components, interfaces, and 
development tools wherever possible. This approach has the 
dual benefit of reducing cost as well as taking advantage of 
the most widely used, commercially available products on 
the market and making the results openly available to the 
commercially satellite market for development. 

Flexible Implementation Approach and Technology 
Upgrade Path 

The MIDEX architecture design and implementation 
approach allows users tremendous design flexibility to suit 
custom applications. Using the modular, standardized 
subsystem component designs, future implementations of 
spacecraft subsystems can be configured for particular 
mission requirements by adding or deleting cards to meet 
spacecraft requirements. 

The modular, distributed MIDEX architecture permits new, 
emerging technologies be readily inserted into subsystems in 
a controlled manner without impacting the entire subsystem 
design and development. This allows a clear path to infuse 
new technologies and upgrade hardware without expensive 
and time consuming redesign issues. Previous attempts to 
standardize spacecraft subsystem electronics have often 
resulted in hardware implementations and architectures that 
become self-perpetuating entities, difficult to upgrade with 
emerging new technologies without massive redesign and 
accompanying high NRE. As a result, spacecraft electronics 
hardware either remains static and increasingly obsolete and 
outdated for years despite the availability of emerging new 
technologies, or is redesigned with each successive 
technology development step at tremendous manpower and 


expense. The MIDEX architecture implementation 
approach allows new technology insertion efforts to be 
isolated in such a manner as to avoid both of these 
extremes, allowing designers to easily focus on key areas 
where emerging technology can be targeted to further the 
goal of increasing spacecraft capability while lowering 
overall cost. 

Partnerships with Industry 

As part of this effort, the MIDEX implementation approach 
has joined in GSFC’s ongoing partnerships with industry to 
develop components, standards and tools that further the 
goal of increasing capability and lowering costs. Many of 
the key emerging technologies that have enabled the 
MIDEX architecture implementation have been the result of 
joint development arrangements with commercial 
companies. For example, the rad-hard Mongoose V 32-bit 
RSIC processor was developed as part of a joint effort 
between GSFC, Synova Corp., and Honeywell SSEC; the 
ESN was developed in a partnership between GSFC and 
Honeywell Space Systems; the Boeing AS 1 773 fiber optic 
transceiver was part of a collaboration between GSFC and 
Boeing; and the MIDEX primary spacecraft avionics 
components were developed in collaboration with Litton 
Amecom under a NASA Space Act agreement. 

5. Conclusion 

The MIDEX architecture, as demonstrated in the ongoing 
MAP spacecraft hardware development effort, has shown 
itself to be a simple, more capable, and less expensive 
spacecraft electronics implementation approach than 
previous spacecraft implementations. The development 
costs per electronics subsystem are anticipated to be less 
than a third of previous missions, while still providing an 
increase in overall performance capability. The modular 
architecture has a broad applicability to a wide range of 
spacecraft missions, from low-end missions to those 
requiring full redundancy and cross-strapping of spacecraft 
subsystem avionics. In addition, future upgrades are already 
envisioned which will continue to increase capability while 
lowering cost. The modular nature of the MIDEX 
architecture allows a smooth insertion of these types of 
upgrades without requiring significant redesign of entire 
subsystems. 

The MIDEX architecture hardware development for 
implementation in the MAP spacecraft development 
program is being performed as part of the in-house 
spacecraft development effort at GSFC. Flight unit 
environmental testing of all spacecraft avionics is schedule 
for completion in Spring 1998. This is to be followed 
extensive testing on the MAP “flatsat” (dedicated ’’flight- 
like” benchtop avionics testbed) and culminating with actual 
integration onto the MAP spacecraft in Summer 1998. 
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